<?php
/**
 * <https://y.st./>
 * Copyright © 2016 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'<{title}>' => "The Wget and $a[cURL] people prefer buggy behavior over following standards",
	'<{body}>' => <<<END
<p>
	I was speaking to someone about telephone numbers this morning, so I thought that I&apos;d post my thoughts on the matter here as well.
	The problem with telephone numbers is twofold.
	First, people are expected to enter them directly into their calling devices.
	This is moronic.
	This would be like expecting people to enter $a[IP] addresses when trying to access websites or expecting emails to be sent to &quot;{user}@\{$a[IP] address}&quot;.
	$a[IP] addresses, like telephone numbers, are meaningful to the machines, but not meaningful to people.
	However, people are still expected to memorize these numbers.
	When people link to services by $a[IP] address, at least they do so because they would rather use a number than a name.
	They <strong>*choose*</strong> to use a number.
	With telephone numbers, there&apos;s no choice.
	There isn&apos;t an option to use a name.
</p>
<p>
	As a side note, it&apos;s worth noting that when faced with the problem of telephone numbers being linked to a specific service provider and being lost if you switch service providers (just like how you lose your $a[IP] address if you switch $a[ISP]s), telephone architects took the wrong approach.
	It used to be that telephone numbers were like $a[IP] addresses, telling the machines where to find the call destination.
	Instead of adding the use a centralized-yet-somewhat-distributed name system such as $a[DNS], telephone numbers (at least in the United States) were modified to no longer mean anything to the machines.
	They are now &quot;portable&quot;, meaning that telephone numbers are looked up my the machines from a big lookup table like $a[DNS] names are.
	So instead of fixing the problem, it was made worse.
	Telephone numbers are meaningless both to humans and machines now.
</p>
<p>
	The second issue with telephone numbers is that people are expected to identify by them.
	I don&apos;t mind identifying by a human-readable and easily-memorable email address, but in many, many systems, your telephone number is your de facto identifier, as if a telephone number means anything at all.
	This is ridiculous.
</p>
<p>
	On the topic of malformed $a[SNI] host names, the person commenting on the <a href="https://savannah.gnu.org/bugs/?47408">Wget bug report page</a> mentions that the problem is present in three other Web browsers, as if that makes it okay.
	Then, he continues that <a href="apt:curl">$a[cURL]</a> strips the trailing dot off of both the $a[HTTP] Host header as well as the $a[SNI] host name, as if this other nonstandard behavior is another option to consider implementing in <a href="apt:wget">Wget</a>.
	I ended up being sent emails from an out-of-band discussion, and it seems that a patch has been produced to fix the bug, but people are considering either leaving the bug in place or modifying the bug to behave like $a[cURL]&apos;s bug because they think that it would be somehow &quot;more consistent&quot; than having no bug.
	I&apos;d just like to reiterate that fact.
	The Wget people already coded a patch, but would rather not apply it.
	It&apos;s not that they don&apos;t think that the issue is worth the time that it would take to fix it.
	They actually actively prefer the buggy behavior.
	As a side note, it also seems that there is an additional <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1008120">bug report</a> against <a href="apt:iceweasel">Firefox</a> in regards to the issue.
	As the Wget people were discussing the fact that $a[cURL] also didn&apos;t implement the standards correctly, so Wget somehow shouldn&apos;t have to, I thought it best to bring up the fact that I too had noticed the bug in $a[cURL] but had not yet had the time to report it.
	At that point, I was pretty much obligated to report it in $a[cURL] today, but it turns out that the people that want to avoid making Wget follow the standards are in charge of $a[cURL] development.
	In other words, trying to get the issue fixed in $a[cURL] is a waste of time.
</p>
<p>
	My <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1255854">bug report</a> against Firefox has been marked as a duplicate of <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1008120">another bug report</a>, but this other bug report suggests implementing $a[cURL]&apos;s buggy behavior of also stripping the trailing dot of of the $a[HTTP] Host header.
	This doesn&apos;t bode well.
</p>
<p>
	I&apos;ve come to the conclusion that I won&apos;t allow the fact that Web clients don&apos;t implement the standards to stop me from using <a href="https://y.st./"><code>https://y.st./</code></a> as the canonical version of my $a[URI].
	I will report the error to as many Web clients as I can find and test, then wait for Debian 9 to come out.
	Debian releases take forever to come out, so this arbitrary deadline will give developers plenty of time to fix their software.
	After that, I will put my <code>https://y.st/</code> to <code>https://y.st./</code> redirect into place (assuming that I am able to run my own clearnet Web server at that point).
	$a[cURL] and any client that has a similar bug as $a[cURL] will get stuck in redirect loops until they give up.
	Any client that instead has the malformed $a[SNI] host name bug will either be presented with an error page (<a href="apt:apache2">Apache</a>&apos;s default) or will be presented with a version of the wanted page that has been modified to include an error message about the malformed $a[SNI] host name and a link to a page explaining more.
	I can&apos;t force people to care about their bugs or agree that they should be fixed, but I shouldn&apos;t allow their refusal to follow standards prevent me from using a completely-legitimate $a[URI] of my choosing.
</p>
<p>
	<a href="http://www.joshwoodward.com/">Josh Woodward</a>&apos;s campaign to raise money for his upcoming album, <a href="https://www.kickstarter.com/projects/joshwoodward/josh-woodward-addressed-to-the-stars">Addressed to the Stars</a>, ended today.
	He ended up getting 426.1% of the funding that he was looking for.
	He always gets over-funded when he does these things.
	I&apos;m not sure if he sets small funding goals out of modesty or if he honestly isn&apos;t looking for as much money as he gets.
	It sounds like physical item delivery is expected in April, though it&apos;s the digital music that I&apos;m more interested in.
</p>
<p>
	My goal for the day was to reach the temp agency to get information on how to register for their services.
	It turns out that they have their applications online only, but I now have their Web address and email address.
	While I was out, I also found one place that said to try back in May, found eleven places that were not hiring, found one place that I passed on because they insisted that the paper application be filled out in-store; I didn&apos;t feel I had time, found seven places that said to apply online, dropped off five resumes, picked up five applications, and dropped one application off after having filled it out.
</p>
<p>
	<a href="https://opalrwf4mzmlfmag.onion/">Wowaname</a> is back up on the clearnet, and as a result, so am I (as wowaname is currently hosting my clearnet website).
</p>
<p>
	On <a href="ircs://kitsune6uv4dtdve.onion:6697/%23Volatile">#Volatile</a>, z randomly started trying to convince me that everyone should release their code into the public domain.
	The public domain is only better than copyleft licenses when it is the only thing that exists.
	When it is the only thing that exists, it becomes far greater than anything else that exists now, but as long as things in the public domain can be moved outside the public domain, it is counterproductive to not not use copyleft licenses.
	Copyleft licenses protect our code from becoming nonfree and closed off.
	The public domain offers no such protections.
</p>

END
);
